AWS Transfer Family の設計や導入を検討する際に、設定項目や構成例などの把握すべきポイントをまとめてみた

はじめに

AWS Transfer Familyは、Amazon S3 やAmazon EFS に対してファイルを送受信できる転送サービスです。

Transfer Family の設計や導入検討する際、以下のように設定項目の選択肢が多いため、構成例を含めて抑えておくべきポイントをまとめました。

• プロトコル（SFTP,FTPS,FTP）
• ドメイン（S3,EFS）
• ユーザー管理（サービスマネージド,Directory Service,カスタムIDプロバイダー）
• エンドポイントタイプ(パブリック、VPC内部向け、VPCインターネット向け)

AWS Transfer Familyの概要を知りたい方は、以下の動画参考になります。

前提条件

• FTPSとFTPは、パッシプモードのみ対応。アクティブモードは利用できません
• FTPとFTPSは、STREAM モードのみ対応。
• FTPとFTPSは、データ型はイメージ/バイナリモードのみ対応
• FTPSは、Explicit（明示的な）モードのみ対応。Implicit（暗黙的な）モードは利用できません
• ファイル転送にはSFTP、AS2、FTPS、FTPを使用できます。SCPやHTTPSは使用できません。

利用コマンドにも制限があります。他の詳細な前提条件は下記を一読下さい。

プロトコル

利用できるプロトコルは、４つあります

• FTP
  • ファイルを平文で転送するプロトコル
  • ユーザー名とパスワードを明示的に送信して認証を行う
• FTPS
  • FTPにSSL/TLSを利用して暗号化して転送するプロトコル
  • クライアントとサーバー間で証明書を交換する
• SFTP
  • FTPにSSHを使用して暗号化するプロトコル
  • ユーザー認証にSSH鍵を使用する
• A2S (Applicability Statement 2)
  • ビジネス間データ交換用のメッセージングプロトコル

A2Sは、今回解説しません。

セキュリティ上暗号化されたファイル転送がよいので、まずSFTPの利用検討を行いましょう。

プロトコルの利用制限

ユーザー管理やエンドポイントタイプごとに利用できるプロトコルが異なります。

ユーザー管理とエンドポイントタイプについては、後で説明します。

ユーザー管理	SFTP	FTPS	FTP
サービスマネージド	○	✕	✕
Directory Service	○	○	○
カスタム ID プロバイダー	○	○	○

下記はエンドポイントタイプごとに利用できるプロトコルです。

エンドポイントタイプ	SFTP	FTPS	FTP
パブリック	○	✕	✕
VPC（内部向け）	○	○	○
VPC（インターネット向け）	○	○	✕

プロトコルの複数選択

プロトコルは複数選択可能です。

ただし、複数プロトコルを選択すると、その分利用できるユーザー管理やエンドポイントタイプが狭まります。

例として、SFTP+FTPS+FTPとSFTP+FTPSとFTPS+FTPの場合、利用できるユーザー管理は以下の通りです。

ユーザー管理	SFTP+FTPS+FTP	SFTP+FTPS	FTPS+FTP
サービスマネージド	✕	✕	✕
Directory Service	○	○	○
カスタム ID プロバイダー	○	○	○

利用できるエンドポイントタイプ管理は以下の通りです。

エンドポイントタイプ	SFTP+FTPS+FTP	SFTP+FTPS	FTPS+FTP
パブリック	✕	✕	✕
VPC（内部向け）	○	○	○
VPC（インターネット向け）	✕	○	✕

ドメイン

選択したプロトコル経由でデータを保存し、アクセス可能なAWSサービスは、以下の２つです

• Amazon S3
  • 耐久性があるストレージサービスであり、データを保存することで、処理、分析、レポート、監査などに利用できます。
• Amazon EFS
  • EC2やオンプレミスサーバーが利用できるファイル共有ストレージサービスです。

ユーザー管理

認証と承認によって、ユーザーのアクセスを管理します。

ユーザー管理方法は、以下の３種類あります。

• サービスマネージド
  • Transfer Familyサービス内でユーザーを作成および管理します
  • 認証方法は、SSHキー認証のみ
• AWS Directory Service
  • AWS Managed Microsoft Active Directory（以降、Managed Microsoft AD）またはオンプレミス環境のAD、EC2インスタンス上に構築したAD（以降、AD on EC2）が利用できます
  • 認証方法は、パスワードのみ
• カスタムIDプロバイダー
  • Lambdaのみを利用するパターンとAPI Gatewayを利用する2パターンがあります
  • 任意のIDプロバイダーもしくは、Secrets Managerにユーザーデータを保存し、ユーザーを管理します
  • 認証方法は、パスワードもしくはSSHキー

ユーザー管理方法別にサポートされる機能は、以下の通りです

機能	サービスマネージド	Managed Microsoft AD	カスタムIDプロバイダー(API Gateway)	カスタムIDプロバイダー(Lambda)
プロトコル	SFTP	SFTP FTPS FTP	SFTP FTPS FTP	SFTP FTPS FTP
SAMLベースの認証	○	✕	○	○
パスワード認証	✕	○	○	○
SSHキー認証	○	✕	○	○
アクセス制御（IAMとPOSIX）*1	○	○	○	○
論理ホームディレクトリ	○	○	○	○
AWS WAF	✕	✕	✕	○

*1 アクセスを制御するために使用され、IAM は S3、POSIX は EFS で使用されます。

WAFを利用するなら、API Gateway一択です。

Directory Serviceでは、SSHキーでの認証はできません。

サービスマネージドは、SFTPのみ利用可能なプロトコルのため、パスワード認証は不可です。

1. サービスマネージド

AWSマネジメントコンソール上でユーザーを作成および管理ができます。

ただし、プロトコルのうちFTPSとFTPは、利用できません。SFTPのみが利用できます。

構成例

実際の構築は、下記の記事が参考になります。

2. Directory Service

Transfer Familyでは、Active Directoryによるユーザー認証が可能です。

AWSでは、Microsoft Windowsの「Active Directory」をマネージドサービスとして提供するAWS Directory Serviceがあります。

Directory Serviceには、３つのディレクトリタイプがあります。

• Managed Microsoft AD
• Simple AD
• AD Connector

このうち、Simple ADは、Transfer Familyではサポートされておりません。

また、Transfer Family サーバーと同じリージョンにあるActive Directory統合のみをサポートしています。

ADとして、Managed Microsoft ADを利用したい場合、そのままManaged Microsoft ADを選択します。

オンプレミスのADやAD on EC2を利用したい場合、Managed Microsoft ADと信頼関係を設定するか、AD Connectorと連携する必要があります。

構成例

Managed Microsoft ADを利用する場合

実際の構築は、下記の記事が参考になります。

オンプレミスのADやAD on EC2をAD Connectorで接続する場合

オンプレミスのADやAD on EC2とManaged Microsoft ADで信頼関係を設定する場合

3. カスタムIDプロバイダー（Lambda）

カスタムIDプロバイダーでは、AWS Lambdaを認証に使用します。

ログイン認証情報を使用してユーザーを認証および承認する構成は、以下の CloudFormationテンプレートが用意されています。

• Secrets Manager テンプレート
  • Secrets Managerにユーザー名やパスワード、SFTPの場合、SSHキーのログイン認証情報を保存します。
• oktaテンプレート
  • oktaを利用したSAML認証です
• okta-MFAテンプレート
  • 多要素認証を加えたoktaを利用したSAML認証です
• Azure Active Directoryテンプレート
  • Azure ADを利用した認証方法です

各テンプレートは、ドキュメントからダウンロードできます

oktaやAzure ADを利用していない場合、Secrets Managerの利用がおすすめです。

Secrets Manager テンプレートの注意点としては、Secrets Managerに保存するユーザー名とパスワードは、１つのみであり、1つのログイン情報しか保存できない点です。

複数のログイン情報を保存して利用するには、Lambdaのコードを修正する必要があります。

また、実際に利用する場合パスワード認証は、安易なパスワードを作成できないようにしたり、ログインの失敗回数を制限することが望ましいです

構成例

Secrets Managerを利用したパスワード認証やSSHキー認証

実際の構築は、下記の記事が参考になります。

Lambdaのみでパスワード認証

実際の構築は、下記の記事が参考になります。

Azure ADを利用する場合

実際の構築は、下記の記事が参考になります。

4. カスタムIDプロバイダー（API Gateway）

カスタムIDプロバイダーでは、Lambdaに加えてAPI Gatewayを使用した認証が可能です。

Lambdaのみと比較し、AWS WAF を使用して地域ブロックまたはレート制限リクエストの機能を活用できます。

ただし、制限事項として以下の２点はサポートされておりません

• カスタム ドメインはサポートされません
• プライベート APIはサポートされません。

構成例

Secrets Managerを利用したパスワード認証やSSHキー認証の場合

API Gateway にWAFの導入が可能です。

oktaを利用したSAML認証の場合

実際の構築は、下記の記事が参考になります。

エンドポイントタイプ

クライアントからTransfer Familyエンドポイントにアクセスするには、３つタイプがあります

• パブリック
  • クライアントがインターネット経由でアクセスできます
• VPCでホスト（内部向け）
  • エンドポイントのプライベート IP アドレスを使用して、アクセスします
• VPCでホスト（インターネット向け）
  • 各ENIにElastic IP アドレスを割り当ててアクセスします。

エンドポイントタイプごとの特徴は、下記の通りです。

項目	パブリック	VPC（内部向け）	VPC（インターネット向け）
プロトコル	SFTP	SFTP FTP FTPS	SFTP FTPS
アクセス	インターネット経由	VPC経由。 オンプレからDirect ConnectやVPN経由でVPCに接続。	インターネット経由。 VPC経由。 オンプレからDirect ConnectやVPN経由でVPCに接続。
固定 IP アドレス	✕	✕	○（Elastic IP）
送信元IP制限	✕	VPCエンドポイントのセキュリティグループやNACLで制限可能	ENIのセキュリティグループやNACLで制限可能
クライアント側のファイアウォール	サーバーのDNS名を許可	サーバーのDNS名やエンドポイントのプライベートIPアドレス許可	サーバーのDNS名やElastic IPアドレスを許可

VPC（インターネット向け）は、FTPプロトコルが利用できません

1. パブリック

パブリックな環境からS3やEFSファイル転送が可能です。

AWSからエンドポイントが払い出されるため、以下のSFTPコマンドでTransfer サーバーに接続できます。

	
$ sftp -i 秘密鍵 ユーザー名@エンドポイント名

エンドポイント名は、Route 53などのDNSでCNAMEにすることもできます。

ちなみに、EFSのマウントターゲットのセキュリティグループは、不要です。

構成例

パブリックの構成で、EFSにファイル転送する実際の構築は、下記の記事が参考になります。

2. VPC（内部向け）

サブネット上で、VPCエンドポイントが自動生成され、設定したセキュリティグループがアタッチされます。

VPCエンドポイントのセキュリティグループのインバウンドルールは、EC2からのアクセスを許可する必要があります。

Transferサーバーに接続する方法は、下記の通りです。

• VPCエンドポイントのプライベートIP
• VPCエンドポイントのDNS
• Route53のパブリックホストゾーンやプライベートホストゾーンで上記２つのいずれかを名前解決

構成例

VPCエンドポイントと同じVPCに存在するEC2がファイル転送する場合

オンプレサーバーから、Direct ConnectやVPN経由でVPCエンドポイントを利用する場合

オンプレサーバーからVPCエンドポイント経由でファイル転送するためには、エンドポイントの固有のURL(例: vpce-xxx.ap-northeast-1.vpce.amazonaws.com)をターゲットに指定します。

下記の記事が参考になります

3. VPC（インターネット向け）

パブリックサブネット上で、VPCエンドポイントが自動生成され、設定したセキュリティグループがアタッチされます。

ENIにアタッチされたセキュリティグループのインバウンドルールによって、ファイル転送するユーザーのIP制限が可能です。

Transferサーバーに接続する方法は、下記の通りです。VPC（インターネット向け）は、VPC（内部向け）としても利用できます。

• インターネット向け
  • Transfer Familyエンドポイント
  • VPCエンドポイントのENIのElastic IP
  • Route53のパブリックホストゾーンで、上記２つのいずれかを名前解決
    • カスタムホスト名を指定すると、Route53のパブリックホストゾーンに自動追加されます。
• 内部向け
  • VPCエンドポイントのプライベートIP
  • VPCエンドポイントのDNS
  • Route53のパブリックホストゾーンやプライベートホストゾーンで上記２つのいずれかを名前解決

構成例

インターネットからVPCエンドポイント経由でファイル転送する場合

VPC内部からVPCエンドポイント経由でファイル転送する場合（VPC内部からのアクセスも可能です）

プロトコルがSFTPで、EFSにファイル転送する構築手順は、下記の記事が参考になります。

プロトコルがFTPSで、S3にファイル転送する構築手順は、下記の記事が参考になります。

AD Connectorを利用したAD認証

AD Connectorは、他のAWSアカウントと共有することはできません。

そのため、AD Connectorを利用し、AD認証を利用する場合、AD Connectorは、Transfer Familyと同じアカウント内に作成する必要があります。

ただし、Transfer Familyは、VPC内に作成されるのではなく、リージョンサービスですので、Transfer FamilyのVPCエンドポイントと同じVPCに、AD Connectorを作成する必要はありません。

下記の構成の場合、右側のAccount Bでは、アカウント内の全てのTransfer Familyは、AD Connectorを利用し、AD認証可能です。

料金

東京リージョンの料金です

項目	料金
各プロトコルの有効時間	0.30USD/時間 ✕ プロトコル数
データアップロード	0.04USD/GB
データダウンロード	0.04USD/GB

各プロトコルの有効時間とは、Transfer Familyサーバーを作成してから削除するまでの時間です。

サーバーを停止しても料金は課金され続けます。

また、接続可能なプロトコル数がFTPとSFTPの２つの場合、料金が2倍かかります。

例えば、FTPとSFTPのプロトコルを有効にすると、1時間で0.60USD掛かります。（0.30USD ✕ 2）

エンドポイントを作成する際に選択するサブネット数は、料金に影響しません。サブネットを1つ選択する場合とサブネット2つ選択すると場合では、料金は変わりません。

また、Transfer Familyを作成すると、VPCエンドポイントが自動作成されますが、VPCエンドポイントの料金はかかりません。

監視項目

CloudWatch メトリクス

Transfer Familyで取得できるCloudWatch メトリクスは、下記にまとめられています。

Transfer Familyはマネージドサービスなので、ユーザー側でCPUなどを監視する必要はありません。そもそもCPUなどのメトリクスはありません。

そのため、Transfer Familyのユーザーへのファイルアクセスの権限(IAM)周りやS3バケットポリシーなどのユーザー起因で疎通ができない事象場合に検知する方法を記載します。

CloudWatchメトリクスには、FilesInというサーバーに転送されたファイルの合計数をカウントするメトリクスがあります。5分間周期で表示されます。

そのメトリクスを利用し、EC2やLambdaで、1分間に一回、ファイルをアップロードするスクリプトを定期実行して、5分間に1件もファイルが転送されていなければアラートするなどの設定で外形監視することは可能です。

また、Transfer FamilyでのAWS基盤側の障害発生時の通知のみでよければ、AWS HealthというAWSサービスの障害発生を通知するサービスがありますので、EventBridge + SNSでメール通知する構成も考えられます。

CloudWatch Logs

また、CloudWatch Logsにログを記録することも可能です。

ログで記録される内容は、ログインや認証失敗、アップロード成功や失敗などのファイル操作やワークフローのアクションなどです。下記にまとめられています。

監視項目は、システムによって変わりますが、認証失敗が多い場合、不正アクセスの疑いがありますので監視したほうがよいですね。

ただし、不特定多数のクライアントがTransfer Familyを利用しパブリックに公開されている場合、ログインを行う前に不正なログインを試みているクライアントであるかどうかを判別することができないために、不正ログインの試み自体を減らすことは難しいです。

想定されていないクライアントからのログインが成功してしまうことを防ぐために、Active Directory で設定するパスワードを強力なものとすることや、定期的にパスワードの変更を行うことをご検討するとよいかと思います。

参照